Memory devices, including Dynamic Random Access Memories (DRAMs), are implemented as integrated circuits (ICs). The decreased size, increased storage capacity, increased operating speed, and expanded capabilities of memory device ICs have revolutionized computer systems, telecommunications equipment and consumer electronics. However, these attributes have also created a number of technical challenges. Testing is one such challenge.
Integrated circuits implementing memory devices must be reliable. Accordingly, memory devices have been tested since their first manufacture. Very early in the history of memory device testing, specialized equipment and automated test routines were developed to improve testing efficiency. As the capacity and capabilities of memory devices increased, a broad range of tests were automated. Different memory device manufacturers prescribed different testing routines. Test equipment is typically custom and memory device testing routines were written specific to the custom test equipment.
Tests for memory devices may be conveniently divided into two categories; xe2x80x9ctest vectors,xe2x80x9d and xe2x80x9calgorithmic patterns.xe2x80x9d A test vector typically consists of a linear set of operations to be performed. A test vector is often written in lower level language like assembly code. Test vectors access one or more memory device components and directly test their functionality over a range of common and end cases. For example, a write buffer might be run through a series of read/write sequences to verify correct operation.
An algorithmic pattern typically consists of a program written in a higher level language which better supports looping and branching constructs for the memory device test. In many conventional implementations, algorithmic patterns are written in a language that looks like a cross between microcode and assembly language. Such xe2x80x9clanguagesxe2x80x9d provide a richer set of control commands and expressions. Unfortunately, algorithmic patterns tend to generate some quirky side-effects within the test equipment. For example, dedicated hardware registers in the test equipment may become corrupted with invalid data during the generation of complicated test patterns. Such problems not withstanding, algorithmic patterns remain a mainstay of memory device test protocols. This is not surprising given the great number of memory locations which must be tested in contemporary memory devices. The practical implementation of a test which repeatedly writes data patterns to every location in a memory device requires some sort of looping operation. A set of linear test vectors sufficient to test the full storage capacity of contemporary memory deices would be impossibly long.
A xe2x80x9ctestxe2x80x9d consists of one or more test vectors and/or one or more algorithmic patterns. In creating a test, a test writer must define a sequence of operations which store and retrieve data to/from the memory device in accordance with certain xe2x80x9coperating constraints.xe2x80x9d Operating constraints take many forms including state-based and timing-based constraints, as well as other constraints which govern the proper operation of the memory device. (Attempting to CAS a bank of memory before it has been properly RASed in one example of a state-based constraint being violated. Attempting to CAS a memory bank too soon after it was RASed is an example of a timing constraint being violated). The operation of early memory devices was simple and characterized by relatively few constraints. As memory devices have increased in complexity, a greater number of operating constraints have arisen. These constraints must be observed and accounted for during the definition and creation of a test.
Contemporary memory devices allow multiple transactions to be handled simultaneously. Compared to their predecessors, contemporary memory devices have an increased number of operating constraints which must be obeyed during a sequence of memory system operations. Further, the use of packets to exchange control/address information and data greatly expands the number of constraints which must be obeyed during the definition of a memory device test protocol. Not only does the number of constraints (or rules) increase for each individual transaction defined within the test protocol, but also the number of interactions between the various rules increases as multiple concurrent transactions are performed to fully test the capabilities of the memory device.
All of the foregoing has created quite a mess. Each memory device manufacturer prescribes a set of tests which targets different aspects of their particular design. Memory device test writers currently generate test protocols without benefit of a tool which provides feedback as to whether or not a test step or test routine violates one or more memory device constraints.
Accordingly, when a memory device fails a test, it is not certain whether the memory device is truly broken, or whether the test has been improperly constructed. In such circumstances, the test writer might ask the memory device designers whether the present interpretation of memory device constraints is correct. However, even if the interpretation is correct, the constraints may not be properly expressed in the written test code. Often a memory device xe2x80x9cknown-to-be-goodxe2x80x9d is used to test the test. This method presumes that the xe2x80x9cknown-goodxe2x80x9d memory device is still good despite its repeated handling in the test facility.
The flowchart of FIG. 1 illustrates a typical conventional process through which a memory device test is generated. Using current interpretations of memory device constraints, a test is created 2, and run 3 on a memory device. If the memory device passes the test (4=yes), the test and the memory device are assumed to be good. As mentioned above, this assumption is often bolstered by the use of a xe2x80x9cknown-goodxe2x80x9d memory device during test development.
If the memory device fails the tests (4=no), the test writer is left in doubt as to whether the device failed on its own accord or whether the test is bad 6. Assuming the test has violated some memory device constraint (7=yes), the test is changed 9 and the new test is run 3. If the test writer has confidence in the test (7=no), the memory device is replaced 8 and the test is re-run 3.
The conventional process of test generation thus relies on assumption and xe2x80x9ctrial-and-errorxe2x80x9d tactics to arrive at a test presumed to be good. Further, each new test must be verified against a number of different conditions, such as temperature, data state, power level, etc. The process of test design is lengthy and fraught with doubt. In fact, errors may enter the test design process during any one of steps 2, 5, 6, 7 and 9 in the exemplary process shown in FIG. 1.
For example, a timing constraint, such as the minimum period between RAS-to-CAS (tRCD), might be violated by a test which defines a slightly shorter period than that prescribed by the memory device specification. Using this constraint as an example, one batch of memory devices might pass the test even though the test violates the specification for the devices. As a result, the test and the batch of memory devices are assumed to be good. (Step 5 above). As it turns out, the test violates the minimum tRCD period for the memory device, but the first batch of memory devices were able to tolerate the shorter than specified period for tRCD. Unfortunately, a subsequent batch of memory devices, while in actuality meeting specification, are not able to tolerate the shorter tRCD period defined by the test. Because the test has been assumed xe2x80x9cgood,xe2x80x9d the later batch of memory devices will be considered out-of-specification and may be thrown out. Such an error in the test protocol may not be caught until many good parts have been discarded as bad.
This result arises because the conventional process of generating a test does not include a mechanism for verifying compliance with actual memory device constraints. Only after a number of memory devices have successfully passed a test is the test assumed to be good. The conventional process of test generation thus involves a xe2x80x9cchicken and eggxe2x80x9d problem. In order to verify a test, xe2x80x9cknown-goodxe2x80x9d memory devices are required. However, known-good memory devices can not be identified until a valid set of tests have been run. Currently, this impasse is breached by running a xe2x80x9cmother-of-all-vectorsxe2x80x9d test on memory devices in an attempt to identify known-good memory devices. While such an approach may serve to verify the memory device interface functionality, it can not reasonably test the entire core of the memory device.
In sum, as memory devices (or memory modules comprising a number of memory devices), memory controllers, and the exchange of data between the memory devices and the memory controller become more complex, the process of generating and verifying tests becomes vastly more complex. Beyond a certain level of complexity, effective test generation requires some additional means of verifying the test.
In addition to writing a test which adheres to the increasing multiplicity of memory device constraints, a test writer is motivated to write efficient tests. The time required to perform a test typically rises as memory devices increase in capacity and complexity. Often the goals of writing a complete, constraint compliant test and writing a run-time efficient test are at odds.
The process of generating memory device tests also requires some means for writing and expressing the tests in a higher level language. The current use of low-level commands, such as Direct RDRAM protocol operations, for example, necessitates that test writers be familiar with such cryptic programming means. Such a requirement unduly burdens test writers and inhibits the development of tests.
In a first general aspect, the present invention provides a method by which a test writer may determine whether a proposed test violates any operating constraint for the memory device being tested. A simulator for a collection of one or more memory devices is developed using a parameter list covering all relevant constraints. A test is typically defined by a sequence of time-ordered operations. This time-ordered sequence is passed through the simulator to verify that it adheres to the operating constraints.
Constraint violations are indicated by error messages. The error messages may offer suggested fixes, such as timing adjustments required to place the sequence of operations in compliance with the constraints.
In a second general aspect, the present invention provides a xe2x80x9cpackerxe2x80x9d function. A verified test may be passed through the packer to reduce its run-time in relation to the given constraints.
The present invention further provides methods for addressing the issue of programming language translation. Recognizing that the simulator is compatible with one programming language while a custom tester is compatible with another programming language, the present invention allows translation from one programming language to the other. In such cases, a test may be written in a tester compatible language and translated before verification in the simulator, or the test may be written in a simulator compatible language and translated after verification and run-time reduction.